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REMARKS 
Status Summary 

Claims 1-37 are pending in the present application and presently stand rejected. 
No claims are added, and no claims are cancelled. Therefore, claims 1-37 remain 
pending. 

Request for Telephone Examiner Interview 
Applicants respectfully request a Telephone Examiner Interview when the 
Examiner begins consideration of this response. The Examiner is requested to call 
Applicants representative, Gregory A. Hunt, at 919-493-8000 to schedule the Telephone 
Examiner Interview. 

Claim Rejection - 35 U.S.C. § 103 

Claims 1-21 and 23-37 stand rejected under 35 U.S.C. § 103(a) as being obvious 
over U.S. Patent No. 5,940,487 to Bunch et aL hereinafter referred to as " Bunch ", in 
view of U.S. Patent No. 6,118,936 to Lauer et aL hereinafter referred to as "Layer". 
Claim 22 stands rejected under 35 U.S.C. § 103(c) as being obvious over Bunch in view 
of Lauer and further in view of U.S. Patent No. 6,625,266 to Saari et aL , hereinafter 
referred to as " Saari ". These rejections are respectfully traversed as described below. 

Applicants disclose methods and systems for dynamic, rules-based peg 
counting. According to one method, a user creates peg counter definitions using a 
rules-based language accessible via a graphical user interface. The peg counter 
definitions are downloaded from an administration server to network monitoring site 
collectors. The site collectors automatically detect the new peg counter definitions and 
begin using the new peg counter definitions without ceasing existing peg counting, i.e., 
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"on-the-fly". Peg counter software on the site collectors periodically sends peg counter 
instances to a data gateway server. The data gateway server aggregates the peg 
counter instances generated by the various site collectors into system wide peg counter 
instances. 

For example, independent claims 1 and 17 recite a method and a system for 
dynamic rules-based peg counting. According to either claim, a plurality of site 
collectors receive signaling messages and generate peg counter instances based on 
the signaling messages matching existing peg counter definitions. The peg counter 
instances each include an accumulator value indicating a number of signaling 
messages matching one of the peg counter definitions and an identifier for identifying 
the associated peg counter definition. The site collectors receive new peg counter 
definitions. In response to receiving the new peg counter definitions, the site collectors 
switch to the new peg counter definitions on-the-fly and generate peg counter instances 
based on the new peg counter definitions. Because peg counters can be updated and 
used on-the-fly, peg counter instance generation can be modified without taking the site 
collectors out of service. Such on-the-fly modification is important for peg counting 
applications to capture a complete set of network signaling message counts without 
missing messages due to down time caused by a peg counter change. 

Bunch is related to a programmable call processing system that provides a 
standard call processing process performing call processing according to industry 
standard call models and having at least one customizable call logic program for 
implementing extended subscriber features on a telecommunications switching system. 
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As a preliminary matter, on page 2, the Official Action states, " Bunch discloses 
selective access to CDR (i.e. call detail record) so call logic program can alter them." 
Providing access for a user to modify existing CDRs has absolutely nothing to do with 
modifying peg counters and dynamically adjusting the generation of peg counter 
instances as claimed. For example, a call detail record is a record containing signaling 
messages or signaling message parameters relating to a single call. In contrast, a peg 
counter instance is a count of the number of messages that match the rules defined in a 
peg counter. Thus, the fact that Bunch discloses that a CDR can be modified by a user 
has nothing to do with modifying peg counter definitions as claimed. 

Moreover, on page 4, the Official Action states, " Bunch fails to teach a method 

and system that switches to new peg counter definitions and generate a reply message 

based on the new peg counter definitions." Applicants respectfully submit that this 

passage in the Official Action fails to address the language of claim 17. In particular, 

the quoted language of claim 17 that this portion of the Official Action was intended to 

address is as follows: 

wherein, in response to receiving the new peg counter definitions, the site 
collectors are adapted to switch to the new peg counter definitions on-the- 
fly and to generate peg counter instances based on the new peg counter 
definitions. 

The above-quoted passage from step (c) of claim 17 recites that new peg counter 
definitions are received by the site collectors and the site collectors switch to the new 
definitions on-the-fly. The site collectors begin generating new peg counter instances 
based on the new peg counter definitions. Method claim 1 includes similar language 
with regard to switching to the new peg counter definitions on-the-fly. The above- 
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quoted passage from page 4 of the Official Action relates to generation of a reply 
message and does not mention anything about peg counter definitions or switching to 
new peg counter definitions on-the-fly. Accordingly, for this reason alone, the rejection 
of the claims as unpatentable over Bunch in view of Lauer should be withdrawn. 

Moreover, even assuming that the Official Action had correctly addressed the 
limitations of claim 17, Lauer fails to teach or suggest switching to new peg counter 
definitions on-the-fly or generating peg counter instances using the new peg counter 
definitions as claimed. Lauer is related to a signaling network management system 
(SNMS) that collects network topology, traffic, performance, and fault information, 
correlates the information and displays the information to system operators. The SNMS 
includes a display alarms component for providing the results of SNMS processing to an 
operator and accepting operator input for actions to be performed within SNMS. The 
Examiner relies in the Official Action on a GUI process described in Lauer that is 
associated with each operator. Each GUI process manages a display that is updated 
both upon initialization and when filter changes are requested. The filter defines the 
specific operator view and can be modified by an operator to define the view that his/her 
GUI process will display. As events are received, the operators GUI display is updated. 
See col. 12, 1. 4 to col. 13, 1. 10 of Lauer . 

Nowhere does Lauer disclose or suggest site collectors that are adapted to 
switch to the new peg counter definitions on-the-fly and to generate peg counter 
instances based on the new peg counter definitions, as defined in claim 17. On pages 4 
and 5, the Official Action indicates that the dynamic updating of screens of a GUI 
display in Lauer teaches or suggests this feature. The updating of a display based on 
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new information, however, does not disclose or suggest switching to new peg counter 
definitions on-the-fly. The same definitions are applied for each event received. 

The Examiner also contends that the filter updates in Lauer discloses this 
feature. For example, on page 4, the Official Action states, "More importantly, Lauer 
even discloses using a GUI display wherein the displays are updated both upon 
initialization and when filter changes are requested (columns 11 and 12)." The filter 
updates mentioned in Layer, however, are not switched to on-the-fly, as in claim 1 or 
claim 17. Lauer discloses if the event is determined to be a filter change request, then 
"the GUI process registers with Process Events 402 so that the appropriate alarms 
records are transmitted" (col. 13, II. 13-16). Therefore, the GUI process must register 
the changes before processing the new events. Accordingly, changes are not made on- 
the-fly. Moreover, even assuming that the filter changes in Lauer are made on-the-fly, 
the filters relate to alarm events, which have nothing to do with peg counters. 

Because Bunch and Lauer fail to teach or suggest a method or a system where 
peg counter definitions are changed and used to create new peg counter instances on- 
the-fly, it is respectfully submitted that the rejection of claims 1 and 17 and their 
dependent claims should be withdrawn. 

Regarding the rejections of claims 28-37 as unpatentable over Bunch in view of 
Lauer , Bunch and Lauer fail to teach a computer program product that includes 
instructions for performing steps including presenting the user with a computer based 
graphical template for defining a peg counter, receiving input from the user via the 
template regarding parameter values to be extracted from received signaling messages, 
receiving input from the user via the template regarding values to be compared with the 
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extracted parameter values, receiving input from the user via the template regarding 
equations for comparing the extracted parameter values to the values specified in step 
(c), and receiving input from the user via the template regarding logical operators for 
combining equations to form a definition for the peg counter. As stated above, neither 
Lauer nor Bunch discloses methods for updating peg counter definitions. The portions 
of Bunch relied upon in the Official Action regarding peg counter definition relate to CDR 
definition. The portions of Lauer relied upon in the Official Action regarding peg counter 
definition relate to display and alarm filter changes. Accordingly, for this reason alone, 
the rejection of claims 28-37 as unpatentable over Bunch in view of Lauer should be 
withdrawn. 

Moreover, the Official Action fails to address the elements of claims 28-37, 
stating only that these claims are rejected for the same reasons as claims 1-16. The 
cited art, however, fails to disclose at least some of these features. For example, 
neither Lauer nor Bunch teaches or suggests "receiving input from the user via the 
template regarding equations for comparing the extracted parameter values to the 
values specified," as claimed in independent claim 28. 

Moreover, neither Bunch , nor Lauer teaches or suggests "receiving input from 
the user via the template regarding logical operators for combining equations to form a 
definition for the peg counter," as claimed in claim 28. 

Accordingly, it is respectfully submitted that computer product claim 28 is in 
condition for allowance. In addition, corresponding dependent claims 29-37 are also in 
condition for allowance for at least the same reasons. 
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Regarding the rejection of claim 22, claim 22 depends from claim 17. As stated 
above, Bunch and Lauer fail to teach dynamic peg counter updating as claimed in claim 
17. Saari likewise lack such teaching or suggestion. Saari relates to a system that 
includes report request service blocks and counter service blocks that each monitor one 
or more counters. The counter service blocks read the counter values and send them 
to the report request service blocks in a message. Saari also does not disclose or 
suggest switching to new peg counter definitions on-the-fly. On page 6, the Official 
Action indicates that the right hand side of Figure 2 of Saari mentions peg counters. 
Applicants have reviewed Figure 2 and note that there is no mention in Figure 2 of peg 
counters. Accordingly, the rejection of claim of 22 as unpatentable over Bunch in view 
of Lauer and further in view of Saari should be withdrawn for this reason alone. 

Moreover, even assuming for the sake of argument that Saari teaches peg 

counters, Saari fails to teach receiving new peg counter definitions and automatically 

switching to the new peg counter definitions on-the-fly generate new peg counter 

instances based on the peg counter definitions as claimed. With regard to that a new 

counter service block must be created together with proper counters to fulfill a new 

feature request. For example, Saari states: 

The feature management block creates a new counter service block 
together with proper counters connected to it, whereby the created new 
counter service block will carry out the request. (See column 6, lines 61-64 
of Saari .) 

From this passage, Saari indicates that a new counter service block is required to 
implement new counts. In contrast, the site collectors of the subject matter of claims 1 
and 17 automatically switch and begin using new peg counter definitions on-the-fly. No 
new software is required. Accordingly, it is respectfully submitted that the rejection of 
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claim 22 as unpatentable over Bunch in view of Lauer and further in view of Saari 
should be withdrawn. 



In light of the above amendments and remarks, it is respectfully submitted that 
the present application is now in proper condition for allowance, and an early notice to 
such effect is earnestly solicited. 

If any small matter should remain outstanding after the Patent Examiner has had 
an opportunity to review the above Remarks, the Patent Examiner is respectfully 
requested to telephone the undersigned patent attorney in order to resolve these 
matters and avoid the issuance of another Official Action . 

DEPOSIT ACCOUNT 
The Commissioner is hereby authorized to charge any fees associated with the 
filing of this correspondence to Deposit Account No. 50-0426 . 

Respectfully submitted, 

JENKINS, WILSON & TAYLOR, P.A. 
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